「你覺得有天才這件事情嗎?」

我本來也認為這世界上真的有天才，直到我看到《刻意練習》中，在描述我們認為各領域的大師們成長的過程，是多少環境的營造，與自身的努力，還有每一次練習中不斷排除萬難的創新精神，才能造就我們所見到的天才。

光是練習「一萬小時法則」是沒用的，如果沒有「刻意」的在每一次的練習中，每天進步一點，每次都加一點創新，每次都刻意去下定目標，補足自己在某項專精領域上還欠缺的某一小部分，而是一萬個小時都重複練習一模一樣的東西，最後是無法從該領域的庸才變成該領域的專家或大師的。就像金庸小說裡的大俠郭靖，天生資質魯鈍，但生性忠義、且勤於潛心修練《九陰真經》與《降龍十八掌》，最終成為萬民景仰的一代大俠。

而已經成為該領域的專家或大師的人，為什麼都能一直保持屹立不搖的專業與學習能量? 我的觀察是，因為他們已經把上述的事情變成習慣，習慣去「刻意」磨練自己還不夠的地方，即使自己已經是大師級的人物，還是攪盡腦汁去突破自己；比如我去看已故漫畫家-鄭問的展覽，他的一生就是在不斷的「刻意」突破自己中漸漸茁壯成長，才有今日亞洲至寶的成就。

必須強調，刻意練習真的是「刻意」的，你必須走出舒適圈，就像鐵人賽三十天如此的痛苦，但依然要堅持下去，並每天都精進改變一點點。

最後我想說，這世界有沒有天才並不是重點；重點是，比你優秀的人比你還懂得更努力。

既然說到要「刻意練習」，刻意練習系統分析要怎麼樣去做?

因為在指導年輕的團隊成員，我必須要不斷思索這樣的事情。前兩年開始真正接觸Agile和Scrum之後，開啟了許多面向的思考，從sprint planning到user story的評估，product backlog 漸進明細 和 sprint backlog的refinement，這些形式一步步都是「刻意」逼迫自己釐清問題的本質，Do the Right Thing in the First Time。

後來為補足從user story拆解出來的每個sprint所做的task，彼此間可能無關連，團隊無法事先綜觀產品的全局，而可能造成每個sprint的increment最後合起來不是正確的產品方向，而有了先規劃User Story Mapping(使用者故事對照)的方法。

User Story Mapping是敏捷領域中分析需求的工具之一，由Jeff Patton所提出。利用User Story Mapping讓每個不同專業領域的團隊，能充分溝通產品的價值，確認方向是否是一致的。這就是見樹(每個需求項目User Story)又見林(整體)的意思。

也就是系統分析的一種方式。
最簡易的Mind map(心智圖)其實也是，在想法上可更為發散的去分析。

而傳統的軟體工程，採用UML統一塑模語言進行對整體系統架構的規劃，用於IT人員之間的溝通工具，與統一開發實踐過程的一種標準。但這樣的文件，對於PM或產品規劃人員並不友善，也對年輕的工程師來說，他們無法快速掌握UML這套工具，而且容易陷入制式化的文件產出，而非探究系統層級的問題。

為了讓年輕的團隊成員，能真正了解系統思考，近日我才有幸藉機去拜讀了《第五項修練》這本書。

1990年，《第五項修練》首度問世，至今已快近30年，2018再度改版發行。

書中提到每個人都是天生的學習者。而且學習是沒有止盡的。

有一段話讓我想起在C社，或許你我都有這種經驗: 成為出色團隊中的一份子；在這團隊中，一夥人以極不尋常的方式在一起工作，彼此信任，互補長短，為共同的大目標全力以赴，從而創造出驚人的效果。

這就是學習型組織。

如何建構學習型組織，書中透過五大章節來介紹:

1. 第一項修練: 自我超越(Personal Mastery)
2. 第二項修練: 改善心智模式(Improving Mental Models)
3. 第三項修練: 建立共同願景(Building Shared Visio)
4. 第四項修練: 團隊學習(Team Learning)
5. 第五項修練: 系統思考(Systems Thinking)

其中系統思考最為重要，是要做系統分析前的首要條件。

書中透過循序漸進的解說，讓讀者了解系統的因果關係，並透過一些案例「刻意」練習系統思考。這裡有一個簡單的例子。

假設要你描述「注滿一杯水」這個系統的原理，你會怎麼做?

大多數人的腦子都會像以下圖片的想法。(線性思考)

但書中指出，其實當我們為杯子加水的時候，我們正處於一個涉及至少五項變數的「水量調節」系統內，這邊變因被排列成因果關係的環路，不斷地運作，直到水杯中的水位達到想要的位置為止，被稱作「回饋過程」，如下圖所示。(系統思考)

這邊所說的「回饋」，是一種廣泛的概念，意指任何具有影響力的反覆回流，行成一種循環不息的永動機。

這是一個簡單卻一針見血的例子。

但一般人很少考慮到外在的回饋。以及反覆調節的正向增強。

再舉一個實際在團隊中的案例。

在上週跟同仁分享Clean code的內容，並應用在我們自己前端JS的專案上可以怎麼做。Clean code不是任何工具，沒有像prettier和eslint那樣在vs code上有plug-in。它是一種寫程式的思維，我最喜歡它書中最前面所說的一句對話。

「如果你是醫生，一位病患叫你不要浪費時間在手術前洗淨雙手，請問你會聽他的話嗎?」

很久以前，婦產科醫生在接生孩子時，是不洗手的。所以早期孩子一出生夭折率很高，後來匈牙利的塞麥爾維斯醫生發現，是因為醫生手術前沒有洗手，導致在早上進行例行性大體解剖時，所殘留下來「死屍微粒」感染到孕婦，所造成分娩的高死亡率。後來手術前洗手就被強制執行了。

所以如果你是醫生，請你尊重並堅持你自己的專業。

如果你是工程師，也請你尊重並堅持你自己的專業。

這樣的東西是一種來自外在的正向增強，因為別人會看你的程式碼(code review)。

對，沒有規矩，何來方圓。

其實我以前寫的code也很髒，但經過不斷地「刻意練習」，也不敢說自己現在寫的真的很漂亮，但至少可以敢給別人看程式碼，且別人是看得懂的。寫好clean code很累，我知道。刻意練習很累，我也知道。那你知道別人看你的程式碼很累嗎? 你一定也知道。

團隊規矩即使定了下去，但改變卻不可能是一時一刻就發生。

《第五項修練》書中第八章提到，
「人們不是抗拒改變，人們是抗拒被改變」。也就是改變是要由個體內在自己引發的，唯有從最內心深處的價值觀與信仰下手，才有可能真正改變。這與前面幾篇提到的冰山理論不謀而合。

下一篇，我將提到如何建構學習型組織的細節，要讓團隊成員自我改變。